I am not really sure I understand the idea here: what's basic card payment if not legacy payment? Does it make any sense for a merchant to say 'I'm going to update my site to use this new API, but not support basic card payment and fall back to my legacy form field checkout instead'?

Putting that aside, does it not make more sense for legacy checkout to just be another supportedMethod rather than a boolean property?

I'm not comfortable with this proposal, though I need to think about it a bit more. It seems that it's again something that HTML's form auto fill should satisfy.

@nickjshearer,

There's more discussion following the original proposal here: #316 (comment)

As @ianbjacobs mentioned, there was support for this feature on the most recent call. It could be seen as a more privacy aware alternative to canMakePayment or simply as an orthogonal feature that provides a more graceful fallback when the user cannot or does not want to select a payment method. This could be for a number of reasons, for example, the user has no payment apps, the browser does not support even basic card, or the user simply prefers to use the website experience and already has their card information registered with the site. There are a number of concerns that can be found in that other discussion that pertain to this proposal.

I'm afraid I still don't really understand the need for it: it would make more sense if canMakePayment had been rejected. Sites can use canMakePayment to determine whether their accepted methods of payment (including basic card) are available. So they should already know ahead of time whether the user can pay successfully, meaning this legacy fallback isn't required.

And again, the argument it's more privacy aware would only really be relevant if we hadn't agreed to take canMakePayment. Like Marco I think I'm going to need to think about it some more before being comfortable with it...I have a number of reservations and it seems to be a solution for a problem we already solved.

@nickjshearer,

My understanding is that canMakePayment is not a workable solution in some cases (see the thread linked to above for details from WorldPay). This is to be expected given that it's an API call that arose somewhat from compromise rather than ideals. Furthermore, it may turn out that some browsers implement canMakePayment in a way that prevents it from being an useful filter (i.e. it always returns true). In either of these cases, or simply in the case where a more privacy aware option is desired, having this additional feature is helpful.

In other words, this feature can be seen as an alternative to canMakePayment or as complementary; it can assist in filling in some gaps, given that canMakePayment is not an ideal API.

This feature is particularly useful at the present time, since Payment Request only supports Basic card (and digital wallets), and Payment Apps aren’t quite a “thing” yet.

Consider the use case where a German merchant accepts credit cards, as well as Giropay and Sofort (both redirect-based payment methods which don't exist as Payment Apps yet). At the present time, if we call show() on Payment Request, we’re making the assumption that the user wishes to pay via credit card. However, if they want to pay via GiroPay or Sofort, they must Cancel payment request and hope they can find a way to pay via another method (i.e. it’s not intuitive).

Allowing some form of “Pay via other payment method” link provides a better user experience. It is especially useful in the early days of Payment Apps, when there is a scarcity of payment apps that support Payment Request (however, I agree with a point that was made, which is that this could actually slow adoption of payment request (payment providers won’t necessarily be in a hurry to provide support for Payment Request if they have a “way out”).

I do understand the problem WorldPay are talking about - but a much better way to solve this is just to make the legacy payment option another payment method just like basic card.

The problem with this change as it stands is it's incompatible with our charter. From your pull request (emphasis mine):

If the enableLegacyCheckout value of request@[[\options]] is true, then provide an option on the user interface to complete checkout on the payee's website without selecting a payment method.

And from the WG charter:

This Working Group is chartered to Recommend programming interfaces; not user interfaces.

So I can't see how we can take this since it very clearly defines a user interface requirement, which the WG has explicitly said it's not going to do. Currently the spec is quite careful to always refer to UI in generic terms ("some kind of user interface", "show a user interface that allows a user to interact with a payment request"), and where we do specify UI requirements they're qualified with should. At the very best this requires normative language on the UI requirement, but I'd much rather explore handling this in some other way.

So I can't see how we can take this since it very clearly defines a user interface requirement, which the WG has explicitly said it's not going to do. Currently the spec is quite careful to always refer to UI in generic terms ("some kind of user interface", "show a user interface that allows a user to interact with a payment request"), and where we do specify UI requirements they're qualified with should. At the very best this requires normative language on the UI requirement, but I'd much rather explore handling this in some other way.

We can always use different language. I thought "provide an option on the user interface" was just as generic as "show some kind of user interface". Note, even in the examples you site, vague UI requirements are implied:

Show a user interface to allow the user to interact with the payment request process.
Some kind of user interface will be presented to the user to facilitate the payment request

Both of these impose UI requirements that the user be able to interact with the payment request process or to facilitate it. We have plenty of other statements about "users providing shipping addresses" and so forth that could similarly be taken as UI requirements. We need to at least say why a user interface is necessary.

We can change the language here to direct implementers to show some kind of user interface to let the user exit the payment request process without rejecting it (and without accepting a payment method). Or we can just say "if the user decided to do X" without mentioning user interface at all. Note that we don't need to say anything about the shape of the user interface. So I don't see how this substantively different (wrt to the charter) from other statements already made in the spec.

As you said, we could alternatively create a special "legacy payment method" to capture this intent if that's really necessary, but it raises corner cases that must be addressed like dealing with payment apps asserting that they support this method.

@nickjshearer,

It's intriguing to think about "return to merchant legacy page" as a payment method, and
maybe it could be implemented that way. But I think there are some limitations. If we
call it a payment method then we would:

• Define a short string payment method identifier, such as "payee-legacy"
• Write a payment method specification that expects as input (to the mediator) a URL for a payee legacy page. Question: how would session information be preserved?

Why I don't think it's exactly a payment method:

• This payment method means "stop doing PR API and get me out of here." That would make it unique (at least so far).
• Similarly, this would be a payment method that only mediators should support. I would not expect the user to be taken to a payment app after selecting this option. It also does not feel like taking the user to a Web page should be considered a Web-based payment app in the sense that we are defining in the task force. The primary reason is that we are "killing the PR API call" rather than handing off control and expecting a response.

If I understood the proposal, what is desired is:

• In the list of payment options, show a "More payment options from the merchant" entry.
• When the user selects that, kill the display of choices, then fetch the URL provided by the payee.
  (How does this interact with promises that were created when PR API was invoked?)

Assuming for a moment that there are use cases to motivate this, do browser vendors think
this would make sense to treat this like a payment method, albeit special? Or would that be
inefficient, confusing, etc.?

Ian

Do browser vendors think this would make sense to treat this like a payment method, albeit special? Or would that be inefficient, confusing, etc.?

I don't think that we should be adding either the "payee-legacy" payment method or the "enableLegacyCheckout" option. If a merchant was using the services of https://a-payment-service.com, then "https://a-payment-service.com" should become a payment to participate in the ecosystem.

That being said, if someone defines a payment method called "payee-legacy", which will be used by merchants and payment apps, then that's OK. However, I don't think user agent should be treating this payment method any differently than other payment methods.

Having discussed with the editors/implementers, we are not able to envision a good user experience for enabling the "legacy checkout flow". We are closing this issue, but happy to continue discussion.